The present invention relates to the collection, storage and retrieval of data on computer systems. More particularly, the present invention relates to a method and apparatus for specifying address formats and rule sets for creating address formats for use throughout an information enterprise which facilitate automatic address building and storage for collected records and automatic generation of hyperlinks to stored records via database literate processors.
An exemplary information enterprise includes at least one database (DB), information collecting devices (ICDs) for collecting information to form data records for storage on the DB and one or more processors linked to the DB for running application programs which access and manipulate DB records. For example, U.S. patent application Ser. No. 09/170,169 (hereinafter “the '169 application”) entitled “Data Collection Device and System,” which is commonly owned by the applicant of this application, describes several remote ICD types which collect information and provide the information and corresponding addresses to a DB for storage. For the purposes of this explanation ICDs may also include stationary computers or the like for data entry. U.S. patent application Ser. No. 09/247,349 (hereinafter “the '349 application) entitled “Method and System for Automated Data Storage and Retrieval” which is commonly owned by the applicant of this application, describes a database literate processor application program which automatically builds database addresses for forming hyperlinks between data references to records and the records referenced by the data references. The '349 application also teaches processors which receive information sets and based on set content, generate DB addresses for the sets and store the information sets at the generated addresses. Although the invention may be used with other application programs, to simplify this explanation the invention will be described in the context of the DB literate processor program referenced above. Hereafter DB literate processor is taken to mean any of several different types of data processors including a word processor, a spread sheet, a data entry form and so on.
The proliferation of information systems throughout all aspects of business and personal life is a clear sign that society has recognized the advantages associated with such systems. Nevertheless, conventional information systems are plagued by a number of important shortcomings which render systems difficult to use and therefore, in many cases, underutilized.
First, in most cases it is extremely difficult to develop and maintain an entire information system which is completely information compatible. Information compatibility means that when a record and a corresponding address are provided to the DB for storage, the record information is arranged in a record format required by the DB and the record address is in an address format required by the DB. Information compatibility also means that when a DB literate program identifies a DB record in a record request, the request includes an address format which is recognizable by the DB.
Generally there are two ways to facilitate information compatibility. First, each ICD program and DB literate program may be programmed to provide records and respective storage addresses in record formats and address formats required by the DB. Second, an intermediate computer may be provided which receives information from ICDs and DB literate programs and uses the received information to generate records and respective storage addresses which comport with required DB record and address formats. The intermediate computer effectively operates as a translator between the ICDs and DB literate programs on one hand and the DB on the other hand.
In either case, after a DB characterized by record formats and address formats has been defined, additional custom programming has to be done to support information compatibility. In systems which do not include an intermediate computer, each ICD program and DB literate program has to be programmed to support information compatibility. In the case of an ICD program, this means that the program can recognize information required to form a record and an address, can identify the required information and can assemble the address and record for delivery to the DB. In the case of a DB literate program, this means that the program can recognize a reference to a stored record, can recognize information required to form an address for the referenced record, can identify the required information and can assemble an address for the referenced record. In systems which include an intermediate computer, the computer has to be programmed to receive information from the ICDs and application programs, recognize information required to form a record and/or an address, identify the required information and assemble the record and/or address for delivery to the DB.
Thus, programming an ICD, a DB literate program, or an intermediate computer requires provision of DB address formats and record formats and rule sets for identifying required information to instantiate the formats, rule sets for how to use the identified information to instantiate the formats often including specific information forms and rules for converting the identified information into the specific information forms.
Therefore, conventional systems for defining DB address formats and record formats require at least two programming steps to facilitate information compatibility including DB definition and additional programming of either ICD programs and DB literate programs or additional programming of an intermediate computer.
While two step programming is not particularly difficult where ICDs and application programs are only used with one DB and where the DB only supports one record format and one address format, most information systems include several DBs and each DB typically supports several different record formats and address formats. In addition, most information systems also include many different ICD and application program types, each of which may internally format information in a unique manner and may provide information to an intermediate computer in a unique configuration. These different ICD and application program types further increase programming complexity.
This smorgasbord of different DBs, record formats, address formats, ICD types and application program types is due to the evolutionary nature of information systems generally. Typically information systems grow and expand along with the businesses they serve. For example, an initial system may include one type of ICD and a single application, each of which is supportable by a single programming language. As technology evolves a second ICD type may be developed and added to the system, the second ICD type having to be programmed for DB information compatibility and so on. Similarly, as a business expands, database requirements eventually exceed existing capacity and additional DBs have to be added to the information system. Many times a new DB requires different record formats and address formats. In addition, often different ICDs and applications only support a vendors proprietary software and record and addressing formats.
The second shortcoming of conventional information systems is related closely to the first and is that highly skilled programmers are typically required to facilitate information compatible programming. This is because such programming requires an intimate knowledge of DB record formats and address formats and the form in which ICDs internally store information. In addition, in systems which do not include an intermediate computer, the programmer must have knowledge about the ICD and DB literate program programming languages. In systems which have an intermediate computer the programmer must have knowledge about the intermediate computers programming language. The task of programming is further exacerbated in most cases as most information systems include many different ICD types, application program types and DBs having unique programming characteristics as described above.
Third, modifications to information systems are relatively difficult to implement. Consider the case where a new record format and a new address format are added to a DB or the case where an entirely new DB is added to an information system where the new DB requires new address formats and record formats. In either of these two cases additional customizing programming is required. In systems which do not include an intermediate computer each ICD program and each DB literate program has to be modified to accommodate the new DB record format(s) and address format(s). Also, new rule sets for identifying required information and for instantiating address formats and record formats have to be provided to each ICD and each DB literate program. In systems which include an intermediate computer the intermediate computer has to be reprogrammed to accommodate the new DB record format(s) and address format(s).
Fourth, because highly skilled programmers are required to support and maintain an information system and many businesses do not employ such programmers, often, despite a systems ability to support additional information gathering, storage, retrieval and processing capabilities, a business will not take advantage of such additional capabilities.
For example, in a medical facility ICDs including bar code readers may routinely be used to memorialize physician visits to patients. With a bar coded bracelet on each patient, at the beginning of each patient visit a physician may be required to use the ICD to read the patient's information from the bracelet. The ICD then generates a record including date, time, patient ID, physician ID and so on documenting a patient encounter. The ICD also generates a record address and, when downloaded to a DB, the DB stores the record at the corresponding address.
In this case, it may be advantageous to use the same bar code reading ICD to track other facility information. For example, facility equipment may be bar coded to track location of mobile equipment, medication containers may be bar coded when filled to track dispensation and so on. If the ICDs are used to track equipment location without custom programming equipment locations will be mistaken for patient encounters. Thus, custom programming is required. In this case, while the ICD may be ideal for other facility purposes, the programming task required to support these other capabilities may be prohibitively complex and therefore the additional capabilities may never be realized.
Fifth, especially in systems which include a large number of different devices, applications and DBS, program errors are extremely likely and, unfortunately, because of system complexity debugging is extremely difficult. For example, in the case of an ICD which generates both a data record and a corresponding address for the record from an information set and then downloads the record/address to a DB for storage, if a new record/address format pair is to be supported and each of the ICD and DB have to be programmed to support the new format separately, errors or incompatibilities between the DB and ICD are likely and identifying the errors would be difficult at best.
Therefore, it would be advantageous to have a method and apparatus which could be used to simplify the process of programming all of the components of an information system such that complete information compatibility can be achieved through a single programming process. It would also be advantageous if such a method and/or apparatus could ensure information compatibility.